Data communication devices are used to direct or route requests from clients connected to a network to servers located on the same network. FIGS. 1A, 1B and 2 illustrate different types of routing systems 10 for directing requests to a particular server. Each routing system 10 includes a client 12, a data communications device 14 and a server 16.
FIG. 1A illustrates routing of a packet based upon a destination Internet Protocol (IP) address. Such routing is termed L3 routing. As illustrated, the client 28 sends a packet that includes a request for information 18 to a destination address 30. The data communications device 20 forwards the request 30 to a server 32 having an IP address 15 matching the destination IP address 30 within the request 18. In this example, the data communications device 20 can include a router.
FIG. 1B illustrates routing based on a “flow” 5-tuple consisting of the source and destination IP addresses, the source and destination port numbers, and the protocol type. Such routing is termed L4/L5 routing. A wild card 5-tuple can be used to classify the request in order to direct the packet to a particular destination. As illustrated, a first client 34 and a second client 36 send out a first request 38 and a second request 40, respectively. The requests 38, 40 include similar destination addresses and different port numbers. Requests for the same destination IP address are intercepted by the data communications device 22 and directed to different servers 42, 44 based upon the port number 45 in the request. In this example, the data communications device 22 can include a server load balancer.
FIG. 2 illustrates routing of a request based upon a uniform resource locator (URL). Such routing is termed L7 routing. When a request for a domain name 50 is transmitted by a client 46, a DNS (domain name service) request is issued from the client 46 or its local DNS server to resolve the domain name 50 into an IP address of a server 16 that contains information relating to the domain name. If the domain name is subscribed for data communication device or routing services, the IP address of the data communications device 26 is returned to the client 46. Subsequently, the client 46 makes a connection with the data communications device 26 and sends the request to the appropriate server 16. The data communications device 26 intercepts the request 50 and parses the URL (and the HTTP headers) into an application, a domain name, and an object portion.
The domain name “www.cars.com”, shown in FIG. 2, identifies two data centers in different parts of the world, a first data center 54 located in San Francisco (SF) and a second data center located in New York (NY). Depending on the location of the clients 46, 50, the DNS can resolve “www.cars.com” to either the SF server 54 or the NY 56 server. However, the objects for cars reside on the SF server 54 while the objects for trucks are located at the NY data center 56. Typically, because of their physical proximity, requests from clients 46, 48 located on west coast would be directed to the SF server 54 even if the request called for truck information. The goal of the data communications device 26 is to learn about the distribution of content so the request can be directed to the server that can deliver the requested content directly and most efficiently. In some cases the request can be directed to a proxy cache or replication server that contains a replica of the object requested.
In this example, assume that a client 48 requests a starting web page from www.cars.com. This page can be retrieved from either of the data centers 54, 56. The data communications device 26, located in Phoenix, issues a DNS request to resolve the domain name into an IP address. Because the data communications device 26 is located closer to the server 54 in SF than the server 56 in NY, the IP address of the server 54 in SF (20.20.20.1) is returned to the data communications device 26. The data communications device 26 then returns the IP address of itself (70.70.80.1) to the client 34 as the DNS response. The client 34 connects to the data communications device 26 and forwards the request. The data communications device 26 connects to the server 54 receives the page for www.cars.com and returns it to the client 48. After the www.cars.com page is displayed, the user triggers an option that sends a GET request for a truck image (/trucks/model2.jpeg) at www.cars.com. Again, the DNS request from the client is intercepted by the data communications device 26 and the IP address of the data communications device 26 is returned to the client 48. Next, the client 48 connects to the data communications device 26 and sends the GET request 52 for www.cars.com/trucks/model2.jpeg. The request 52 is initially routed to the SF server 54 (20.20.1.1) and subsequently redirected to the NY server 56 (10.10.1.2), where the requested information is located. The data communications device 26 can dynamically learn or be configured to know the origin servers for all of the content classes for a request and, thereby, route requests to the correct origin server. In the above example, the data communications device 26 can include a content gateway.
Different traffic policies and differentiated services can be signaled by the data communications device. For example, the data communications device can signal that packets transferred between the communications device and the server receive high priority or that the packets be routed over MPLS or IPSEC tunnels. In one arrangement, such policies are triggered by the data communications device based upon the server to which the communications device routes the request. For example, a server can pay a fee such that a particular communications device or series of communications devices routes all received requests to the server with high priority or with a relatively large bandwidth between the device and the server.